The popularity of mobile communication devices such as, for example, mobile telephones, wireless data devices and similar devices has resulted in more and more such devices being used in mobile communication networks. In addition to the growing number of subscribers in such networks, the network operators are also faced with supporting large numbers of devices that are roaming onto their networks.
The capacity of a mobile communication networks is typically statistically engineered based on a number of operating assumptions. When these assumptions are violated the demands for service in the network can exceed the capacity resulting in denial of service for some users (i.e. subscribers and roamers). In an effort to control cost and complexity, network operators ideally plan their networks to have enough capacity for anticipated peak demands within their operating assumption with a small additional margin of capacity.
In order to ensure that users can receive service from the network when they want it, it is necessary that the network operator be able to control access to the network by individual terminal devices (i.e. mobile communication devices). Examples of terminal devices that may be denied access to the network in favor of other devices include: stolen devices, black-market devices, non-subsidized devices, imported devices and devices of types with certain capabilities not supported by the network operator. In addition, some terminal devices may be denied access to the network or to specific services offered in the network based on the devices' lack of certain capabilities and where the user associated with the device does not subscribe to any services (e.g. Push-to-Talk and Push-to-X) that requires a particular capability (e.g. always connected Internet Protocol (IP) access).
During some events such as natural disasters, terrorist attacks or major mishaps, the mobile communication network can become overloaded with a surge in use of the network services. An unfortunate consequence can be that service is denied (by lack of capacity) to responders to the event (e.g. emergency response crews, government agencies and the military) who depend on the network for communications. In these cases it would be desirable to be able to control or limit access to the network to only certain terminal devices on a prioritized basis.
In addition to the situations described above, the network can also suffer from diminished usable capacity when some capacity is lost due to inefficient or ineffective use of the network capacity. For example, when a multimedia message (MM) is sent to a terminal device the multimedia message service center (MMSC) attempts a session initiation request (SIR) with the destination terminal device. If the terminal device is not multimedia message service (MMS) capable the SIR will eventually time-out and the MMSC can attempt sending the MM via another means such as email, a Wireless Application Protocol (WAP) push or a short message (SM) containing a web Universal Resource Locater (URL) referring to the MM content. When a significant number of MM are sent to non-MMS capable terminal devices, then the resulting attempted SIR and time-outs contribute to the inefficient use of network capacity. Furthermore, the time-outs are typically twenty-four hours or longer resulting in the loss of timeliness in delivering the MM.
The effectiveness of the network can also be impacted when senders of significant numbers of messages such as, for example, value added service providers (VASP) do not know the capabilities of destination terminal devices and therefore network assets such as, for example, a MMSC must provide services such as trans-coding of the messages to adapt them to the capabilities of individual terminal devices. Such adaptation is typically inferior to content tailored by a VASP that knows the target device capability.
Lack of information characterizing individual terminal devices in the network and their associated patterns of usage also renders more complex certain activities such as, for example, tracking of specific devices by law enforcement agencies, tracking of stolen devices, authentication and authorization for high security application (e.g. e-commerce, enterprise specific applications), the migration of individual subscribers from one device to a replacement device, and the blocking of junk message (a.k.a. spam) originating devices.
The 3rd Generation Partnership Project (3GPP) technical specification “International Mobile Station Equipment Identities (IMEI)” TS22.016 Release 6 (v 6.0.0) and earlier releases define International Mobile Station Equipment Identities (IMEI) used to uniquely identify a mobile device and an Equipment Identity Register (EIR). The 3rd Generation Partnership Project 2 (3GPP2) technical specification “3G Mobile Equipment Identifier (MEID)” 3GPP2 S.R0048-A (Version 4.0) and earlier versions define a similar mobile device identifier called the Mobile Equipment Identifier (MEID). The 3GPP2 technical specification “MAP Support for the Mobile Equipment Identity (MEID)” 3GPP2 X.S0008-0 (Version 2.0 and earlier versions) defines the validation procedures for MEID) by the EIR. The EIR receives device authorization requests from network elements such as, for example, Mobile Switching Center (MSC), Serving GPRS Support Node (SGSN) and Visitor Location Register (VLR) in the form of a Mobile Application Part (MAP) protocol checkIMEI request or alternatively checkMEID request. The checkIMEI request contains parameters including an international mobile equipment identity (IMEI) and optionally additional identifiers including, for example, an international mobile subscriber identity (IMSI) or a directory number (e.g. Mobile Station International Subscriber Directory Number (MSISDN)). The checkIMEI request can be sent when a terminal device enters the network, when the terminal device attempts to use a service in the network or periodically. As the IMEI and the MEID and their respective validation requests checkIMEI and checkMEID are functionally equivalents, it is to be understood that where the terms IMEI and checksIMEI are used in this document the description applies to the MEID and checkMEID respectively unless otherwise noted.
FIG. 1 is a schematic representation of an exemplary EIR 100 in accordance with 3GPP TS22.016 in a typical network environment. The EIR 100 receives checkIMEI requests, containing the IMEI of a terminal device 108, from MSC 102 or SGSN 104 connected to the mobile network 106. The EIR 100 typically contains a local white list, a local black list and a local grey list. In response to the checkIMEI request the EIR 100 searches the lists 110 for a match to the IMEI contained in the request. The lists 110 are searched in a predetermined order. A response is sent to the originator of the request indicating which list 110 contained the IMEI provided in the checkIMEI request. Inclusion of the IMEI in the white list signifies that the corresponding terminal device 108 is allowed access to the network 106. Inclusion in the black list signifies that the terminal device 108 should be denied access to the network 106. Inclusion in the grey list signifies that the terminal device 108 is subject to special handling such as, for example, being traced in the network 106. If the IMEI contained in the checkIMEI request is not found in any of the lists 110, the response indicates that the IMEI is unknown.